Workflow Management Systems (WFMS) support the modeling and execution of business processes. Business processes executed within a WFMS environment specify which piece of work of a network of pieces of work is carried out in which sequence. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
FIG. 1 illustrates the creation and use of a prior art workflow system. A modeling tool 10 is implemented on a development computer thus providing a developments environment. This tool is used for creating all necessary process definitions, henceforth called the process template, required to implement a given desired business process within the workflow system.
Once the process template is ready, it is deployed on a Workflow Application Server 14 such that instances of it can be executed by a workflow engine 15. The Application Server 14 and the workflow engine 15 are provided with all required interface functionality in order to be operatively connected to a (one of a plurality of) client system 17 acting as participant to the workflow, to a database 16 which stores process relevant business data, and to a staff database 18, present for storing any staff related data required for distributing the activities in the workflow to different staff members.
IBM WebSphere Business Process Choreographer represents such a Workflow Application Server. It supports the definition of business processes as a network of activities. The network of activities, the process template, is constructed from a set of activities which define the individual tasks that need to be carried out. The definition of the process template is done via a graphical editor in a flow definition language such as the Business Process Execution Language for Web Services (BPEL4WS). In this language, the activities are represented using the Web Services Definition Language (WSDL).
As already mentioned, a business process is a network of activities that are executed in an ordered way, either sequentially or in parallel. Such a business process is modeled into a process template, which gets instantiated every time someone sends some data to initiate a process instance for a specific case. Based on that data, internal decisions are made by the process, resulting in a specific navigation path through each instance of the process template.
For example, when requesting a travel approval in a company a series of activities must be done before an approval is obtained. One activity would be to send a message containing the itinerary of the travel request to the first line manager responsible for the requesting staff member. A conditional branch in this process is, for example, if the approximate travel cost is less than 1000 Euro, only the first line manager must approve; otherwise, both the first and the second line manager must approve.
Certain activities referred to herein as “primary activities” of a process have some prerequisites that need to be fulfilled before the primary activities can be executed. For instance, if something has to be sent by postal services it needs to be wrapped first.
Usually, in a business process implemented by a prior art Workflow System, the prerequisites or preconditions are ensured to be fulfilled by activities that are executed directly before the primary activity is actually executed that requires the conditions. Those activities are referred to herein as “preparation activities”. Ordinarily, there is a sequential dependency between the preparation activity and the primary activity.
However in prior an Workflow Systems the primary activity itself has no control means associated with itself for determining whether the preparation activity has already been executed before the primary activity actually starts. In the example of sending a packet, the send activity “does not care” at which time the wrapping activity actually took place.
However, during modeling of processes, humans often keep the preparation activities and the primary activities close together in order to indicate their internal inter-relationship. This is basically a very useful means for providing clarity of the business process in question and thus helps to self-explain and comment the business process to any person occupied with administration and care of the workflow over the years of business practice.
This useful and typically “human” design attitude, however, often results disadvantageously in a logical wait situation during execution, because any primary activity needs to wait for the respective preparation activity to be completed before it may start executing. This waiting time increases the elapsed time of a workflow process to be completed, and results in a respective run-time delay, which is often not tolerable in a modern and efficient business practice and should thus be avoided.
Prior art Workflow systems do not offer a satisfying solution to this problem. Instead, the workflow must be re-designed after having identified such problems. This, however, is quite expensive, as it includes a re-building of the underlying process template and eventually involves a new test phase before the new version can be run in a normal productive way of operation. Further, disadvantageously, it may happen that after the work-flow was re-designed new problems of the same genre arrive, which were not visible before. Thus, possibly multiple iterations of workflow re-design are required before a significant overall workflow improvement may be achieved. This, however, is not tolerable in regard of the typically very high requirements of availability of such workflow systems in most businesses.
It is thus an objective of the present invention to provide a method for running a workflow comprising a sequence of activities of an underlying business process, which has an improved run-time delay, in particular, when pairs of preparation activities and primary activities occur in the business process.